I thought that the Fabric Gateway client API should be runnable directly on Android since it allows the client application to select an appropriate gRPC channel service provider: okhttp for Android and some flavour of Netty for non-Android. See the Fabric Gateway Java README. However, the current grpc-java README says that Android should also use grpc-protobuf-lite instead of grpc-protobuf. This might be a problem since both fabric-gateway and its fabric-protos dependency have a declared dependency on grpc-protobuf. That might be fixable by replacing grpc-protobuf with grpc-protobuf-lite in a client application's Gradle dependency resolution rules. If not, I am open to suggestions on how to resolve that in fabric-gateway and fabric-protos, provided it is not overly disruptive for existing users. This would allow Android devices to talk directly to the peer's Fabric Gateway service without an intermediary server-side Gateway service interacting with Fabric on the client's behalf.

The fabn-895 document you reference talks about off-line signing messages. A similar flow is already available using the Fabric Gateway client API, and referred to as "off-line signing" in the Contract JavaDoc. A less chatty evolution of this existing capability might be to provide utilities that allow the Android client to build (and sign) the protocol buffer messages to be sent to Fabric in their entirety, and then just forwarded to a server-side intermediary to do the gRPC interaction with the peer's Gateway service. It might just about be possible to do this with the existing Fabric Gateway client API using a fake gRPC connection in the Android client application, then extracting the protocol buffer message using the offline-signing APIs to send on to the intermediary using REST or some other mechanism. I prototyped a more streamlined API for achieving this for JavaScript Web clients in this pull request.

@bestbeforetoday thanks for the documents . it ' s great to know that
grpc channel service providers are customizable .

the lab ' s main objective is to let users to connect directly to a
fabric network without an intermediary server and service .

the fabn-895 doc i referred to in the rfc is the one i ' ve implemented
in a low-level , mobile-first platform api for flutter and dart
platforms in connecting to a fabric network :
https://lf-decentralized-trust-labs.github.io/labs/archived/fabric-client-flutter.html
.

this lab is intended to replace the low-level apis with earlier sdk
versions with the high-level fabric-gateway client api . i ' ve
rephrased it in the latest commit in connection with fabn-895 .

in case if communicating through the proposed web api of fabric-gateway
, the dart package can be ported to js / wasm code for web directly and
be used to connect to the web api via js / wasm interface . although
with a intermediary rest server , etc . isn ' t a promised proposal
doing the offline signing .

the other obstacle i could think of is the objective-c / swift api for
the fabric-gateway once the certificate part is cleared on the apple
platforms . i ' ve also updated and reflected this in the latest commit
.